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Introduction 


Numerous planning and scheduling systems employ under- 
lying constraint reasoning systems. Debugging such sys- 
tems involves the search for errors in model rules, constraint 
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stance (initial state and goals). In order to effectively find 
such problems, users must see why each state or action is in 
a plan by tracking causal chains back to part of the initial 
problem instance. They must be able to visualize complex 
relationships among many different entities and distinguish 
between those entities easily. For example, a variable can be' 
in the scope of several constraints, as well as part of a state 
or activity in a plan; the activity can arise as a consequence 
of another activity and a model rule. Finally, they must be 
able to track each logical inference made during planning. 

We have developed PlanWorks , a comprehensive sys- 
tem for debugging constraint-based planning and schedul- 
ing systems. PlanWorks assumes a strong transaction model 
of the entire planning process, including adding and remov- 
ing parts of the constraint network, variable assignment, and 
constraint propagation. A planner logs all transactions to 
a relational database that is tailored to support queries for 
3. vancty of components. Visuuliz&tiOri components consist 
of specialized views to display different forms of data (e.g. 
constraints, activities, resources, and causal links). Each 
view allows user customization in order to display only the 
most relevant information. Inter-view navigation features al- 
low users to rapidly exchange views to examine the trace of 
the process from different perspectives. Transaction query 
mechanisms allow users access to the logged transactions to 
visualize activities across the entire planning process. 

PlanWorks is implemented in Java and employs a MySQL 
relational database back-end. PlanWorks can be used either 
online while planning is performed, or offline after captur- 
ing the entire planning process. Furthermore, PlanWorks is 
an open system allowing for extensions to the transaction 
model to capture new planner algorithms, different classes 
of entity (e.g. complex resource classes) or novel heuris- 
tics. PlanWorks has been used to visualize logs generated by 
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three different planners. PlanWorks was specifically devel- 
oped for the Extensible Universal Remote Operations Plan- 
ning Architecture (EUROPA 2 ) developed at NASA, but the 
underlying principles behind PlanWorks make it useful for 
many' constraint-based planning systems. 

The paper is organized as follows. We first describe some 
fundamentals of EUROPA 2 . We then describe PlanWorks’ 
principal components. We then discuss each component in 
detail, and then describe inter-component navigation fea- 
tures. We close with a discussion of how PlanWorks is used 
to find model flaws. 


europa 2 

EUROPAo provides efficient, customizable Plan Database 
Services that enable the integration of automated planning 
into a wide variety of applications. These services are based 
on some simple building blocks. Plans are composed of 
predicates , each of which has a name, start time, end time, 
duration, and a (possibly empty) set of parameters. Each in- 
stance of a predicate in a plan is represented by a token , and 
each parameter of the predicate is represented by variables. 
Predicates are associated with classes that either represent 
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resources that support possibly concurrent actions that do 
not exceed a maximum capacity. Class instances are ob- 
jects, and during planning each token is assigned to an ob- 
ject in the plan. Domain rules are assertions that if a pred- 
icate P is in a plan, then other predicates Q t must also be 
in a plan, and are related to P by constraints among the 
variables of the predicates. Domain rules may also assert 
that resources are impacted by predicates; resource impacts 
are called transactions, and also have variables that repre- 
sent them. EUROPAzdoes not implement any planning al- 
gorithm; rather, it provides services that support different 
planning algorithms according to the application. 


A Sample Planning Domain 

To illustrate the fundamentals of PlanWorks, we use a plan- 
ning domain loosely based on a planetar}' surface robot 
named Rover. Rover is a mobile robot that can move from 
location to location. A Rover has a battery on board, and can 
replenish its energy levels using solar power. Locations are 
described as follows: 
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class Location { 
int x; int y; 

Location(int _x, int _y){ 
x = _x ; y = _y ; 

} 

} 

The properties of the Rover are described as follows: 

class Rover { 

predicate At{Location 1;} 
predicate Going{Location from; 

Location to;} 

Resource battery; 

battery = new Battery (10, 3, 30); 

} 

A domain rule in EUROPAo describing rover movement 
is: 

Rover: :Going{ 

neq(to, from); // to != from 
meets (object .At aO); 
eq(a0.1, to); 
met _by (object .At al ) ; 
eq(al.l, from); 

subgoal (object .battery .transaction tx) ; 
calcConsumption ( tx. quantity, from, to); 

/ / Consume at the beginning 
eq(tx.time, start); 

} 

Finally, a problem instance for the Rover is: 

Rover spirit = new Rover (); 

Location rock = new Location(l, 1); 

Location hill = new Location(2, 3); 

Location lander = new Location(5, 8); 
goal (Rover .At A); 

eq(A.i, rock); eq (A. object, spirit); 
leq(A. start, 0); leq(0, A. end) ; 
goal ( Rover .At B); 

eq ( B . 1 , lander); eq (B . object , spirit); 
leq(B. start, 0); lea(0, B.end) ; 

Getting Plan Works the Goods 

During planning, EUROPA 2 reads the domain rules to de- 
termine if any of them are applicable given the current state 
of the plan. If so, new tokens, resource transactions, vari- 
ables, and constraints are created, and the domain rule ap- 
plication is recorded. As the planner makes decisions, to- 
kens can be assigned to timelines, transactions can be as- 
signed to resource instances, variables can be assigned, and 
constraints can be enforced, leading to reductions in the do- 
mains of variables. Each of these activities is logged, and 
each entity is assigned a unique key that allows for the track- 
ing of entities and their relationships during planning. This 
information is passed down to Plan Works to enable users to 
uncover the relationships between entities in the plan. 

Plan Works can be used in one of two modes. Planners 
can generate logs for PlanWorks offline, after which Plan- 
Works is invoked to view the logs. When planning takes a 
long time, this is impractical. Alternatively, PlanWorks can 


be started and provided a pointer to a planner. PlanWorks 
then allows the user to interleave planning and debugging. 
The user can run the planner for a fixed number of steps, 
investigate, then continue running the planner or terminate 
planning. 

PlanWorks Components 
Initial Views 

Upon startup, PlanWorks presents users with a menu bar 
offering features for project creation and management. A 
project contains numerous planning sequences correspond- 
ing to the execution of a planner on a problem instance. The 
menu allows users to create new projects, add and delete se- 
quences, and open a sequence for viewing. 

When a sequence is opened for viewing, PlanWorks dis- 
plays two views: the Sequence Step View and the Sequence 
Query View. The Sequence Step View, shown in Figure ??, 
is a broad overview of the planning process. The view is 
presented as an inverted histogram, broken into components 
representing the number of variables, constraints and tokens 
in the plan. Moving the mouse over a bar of the histogram 
shows the step number and number of entities of each type 
in the plan. At a glance, the user sees how the plan’s size 
evolved throughout planning, and can see patterns (such as 
thrashing in a chronological backtracking algorithm, or local 
optimal in a local search planner). An indicator above each 
bar of the histogram shows whether the data for that step has 
been loaded into PlanWorks. 

The Sequence Query View allows the user to request de- 
tailed information about the underlying transactions over the 
entire planning sequence. The scope of logging is crucial to 
support these queries. Each time an entity is created or de- 
stroyed during planning, this information is logged; at cre- 
ation time, each entity is given a unique key. These keys 
make it possible to track entities over the course of planning. 
Constraints can be tracked when they execute, tokens can be 
tracked as their state changes (e.g. from creation to insertion 
on an object), planner decisions can be tracked, and so on. 

Examples of supported transaction queries include entity 
creation, assignments and unassignments .of tokens to ob- 
jects, assignments and unassignments of values to variables, 
constraint enforcement, checking for variables with only one 
domain value remaining, and more. 

The Sequence Step View is also used to launch numer- 
ous other views of the plans generated at each step of the 
sequence. These views fall into one of three categories: 
Plan Views, Entity Relationship Views and Transaction View. 
These views are described further below. 

Plan Views 

Plan Views are holistic views of the entire plan. Plans are 
sequences of states or actions over time, so by their nature, 
the Plan Views are meant to convey a sense of what the plan 
looks like overall. However, EUROPA2 can represent plans 
that are more complex than time-stamped sequences of ac- 
tions. Plans can be temporally flexible ; that is, states may 
have start times or durations that are unknown until plan ex- 
ecution. Further, plans may involve resources whose quan- 


tities change over time. Thus, Plan Works requires visual 
representations of timelines or resources that are temporally 
flexible. For this reason, three distinct Plan Views are pro- 
vided. 


The Timeline View is designed to show the sequence of 
predicates on a timeline. Since tokens can be unified, the 
Timeline View shows the number of unified tokens support- 
ing each predicate; moving the mouse over the predicate 
shows the keys of the unified tokens and indicates which 


of these is the active token. The Timeline View shows the 
possible values of the start and end times of each predicate 
on the timeline. Finally, the Timeline View shows any free 
tokens. This is shown in Figure ??. 

The Temporal Extent View is designed to show more 
temporal information about tokens than the Timeline View. 
Each token has a series of icons representing the possible 
values of the start time (downward pointing triangles), end 
time (upward pointing triangles) and duration (horizontal 
line bracketed by the triangles). This is shown in Figure ??. 
Mo vino the mouse over esch of these shows the v slues snd 
an absolute time scale at the bottom is used for reference. 
By moving back and forth between the Timeline View and 
the Temporal Extent View, users can see how constraints on 
individual tokens lead to bounds and orderings on predicates 
in timelines. The Temporal Extent View also includes each 
resource transaction in the plan. Moving the mouse over the 
resource transaction shows the impact that transaction has 
on the resource. The Resource Transaction View restricts the 
Temporal Extent view so that only the resource transactions 
are shown. 

The Resource Profile View shows the minimum and max- 
imum quantities of a resource available as a function of time 
stemming from the transactions in the plan. Again, moving 
back and forth between the Temporal Extent View (or the 
Resource Transaction View) and the Resource Profile View, 
users can see how resource transactions lead to bounds on 
resource availability. 


Entity Relationship Views 

EUROPA 2 generates a large number of entities during the 
course of planning. These entities range from individual to- 
kens, variables representing their parameters and constraints 
on those variables to object instances and domain rule invo- 
cation instances. The Entity Relationship Views are graphi- 
cal view's that show each of these entities and how' they are 
related to each other. Under the Help menu, the Shapes op- 
tion provides a handy guide to the shape each entity takes on 
in these views. 

The Navigator View is an entity relationship graph capa- 
ble of showing every entity in an individual plan. The Navi- 
gator View is launched by selecting an entity from any other 
view, and initially shows only a small number of entities and 
relationships. Each entity in the Navigator can be "’opened” 
to show its relationships to other (currently hidden) entities, 
and subsequently ’’closed” to hide those relationships. Enti- 
ties that can be closed are outlined in bold, and those that can 



Figure 1: Plan Works Plan Views. The Timeline View and 
Temporal Extent View are shown. 


be closed are not. The entity graph is directed; the descrip- 
tion of the problem defines the initial set of entities, and all 
entities are derived from them via actions taken by the plan- 
ner and the rules of the domain. The graph is acyclic, in 
that multiple relationships between entities apply. Users can 
explore the entities and their relationships and find out how' 
various parts of a plan are related to each other. They may 
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The Navigator Window' also supports a ’’Find Entity Path” 
feature that discovers paths between entities (whether they 
have been opened by the user or not). Navigator View also 
supports a "Find by Key” feature that hilights an entity with 
the given key. Each Rule Instance entity can be expanded 
to show the domain rule text that led to the new token or 
transaction, as w'ell as the tokens involved in that part of the 
view. 


The Token Network View restricts the Navigator view to 
only tokens, transactions and rule instances. This allows the 
user to focus exclusively on the ’’causal chain” that explains 
why particular tokens w'ere generated. The resulting graph 
is a directed tree. As with the Navigator View', each Rule 
Instance entity can be expanded to show the domain rule text 
that led to the new token or transaction, as well as the tokens 
involved in that part of the view'. This is shown in Figure 
??. The Token Network View' also supports the same ’’Find 
Entity Path” and ’’Find by Key” features supported by the 
Navigator. Model constants may be the values of variables. 

The Constraint Network View restricts the Navigator View 
to constraints, variables, tokens, transactions and model con- 


stants. Initially, the view shows all model constants, predi- 
cates, transactions and rules. Model constants may be the 
values of variables, and may be complex structures; for ex- 
ample, in our simple Rover domain, paths consisting of an 
initial location, final location and cost in terms of energy 
consumption are constants. Each model constant can be 
opened to show its underlying structure. Tokens and transac- 
tions are associated with sets of variables, which in turn are 
in the scope of constraints. Domain rules may also have ’’lo- 
cal variables” to reduce the number of parameters of pred- 
icates. The user can incrementally explore the Constraint 
Network by opening tokens, transactions, or rules, and sub- 
sequently opening the variables or constraints. The Con- 
straint Network View also supports the same ’’Find Entity 
Path” and ’’Find by Key” features supported by the Naviga- 
tor. 



Figure 2: PlanWorks Token Network View and Rule In- 
stance. 


Transaction View 

EUROPA 2 was designed to support multiple planning 
paradigms, from heuristically driven chronological back- 
tracking planners to local searching planners to iterative 
sampling planners. Consequently, logging of information 
about how the planner makes decisions is the responsibility 
of the planner, while logging the consequences of planner 
decisions is the responsibility of EUROPA2 . The Trans- 
action View shows every transaction EUROPA2 performed 


this step. This includes checking domain rule applicability, 
entity creation and destruction, variable assignment, token 
state manipulation, constraint enforcement, and so on. 

Navigating PlanWorks 

An early decision was made in PlanWorks to create sep- 
arate Views that contain information that users typically 
want grouped. However, PlanWorks contains numerous fea- 
tures that allow users to efficiently navigate between Views. 
These features allow users of PlanWorks to rapidly move 
from View to View when debugging planning domains and 
planners. 

Launching Views 

Almost all Views can be launched from any other View. The 
Navigator View can be launched when the mouse is over an 
entity such as a token, variable variable, constraint, constant 
or rule in a View (except the Transaction View). All other 
views can be launched when the mouse is over the back- 
ground of a view. 

Tracking Objects by Key 

All objects have keys, and every view has a method to search 
for entities by key. Furthermore, the Views opened on start- 
ing PlanWorks have facilities for querying transactions by 
key. Finally, moving the mouse over entities will reveal the 
keys of entities. The entity relationship views can be used to 
provide keys used for querying the transaction database, for 
example. 

Snapping to Entities 

PlanWorks provides additional features to navigate between 
Views. An entity can be made active in one view, and the 
user can then ’’Snap to Active Entity'” in a second view. This 
is especially useful for getting around the entity relationship 
views. 

Filtering Views 

In addition to manually opening and closing entity relation- 
ships to incrementally explore views, PlanWorks provides a 
custom filter for each View. This filter allows rapid reduction 
of the View to exclude designated predicates, classes (time- 
lines or resources), or predicates in particular time ranges. 

Overviews 

Every View can have an associated Overview window that 
shows the view at a maximum zoom. This allows users to 
simultaneously examine a small number of related entities 
in a View, while also seeing the ’’Big Picture”. 

Stepping Forward and Backwards 

All Views pertain to one step of the planning sequence. Each 
View has buttons that allow the user to advance or retreat the 
step the View shows. This permits a primitive ’’animation” 
feature that shows how a View changes during planning. As 
the View changes, the, window is updated. Furthermore, the 
mouse allows users to either advance or retreat all Views 
simultaneously. 


Managing Views 

All Views are labeled at the top with View name. Project, 
Sequence number and Step. Thus, at a glance, a user can au- 
tomatically tell what information they are seeing in a View. 
In addition, there is a drop-down menu named Window that 
allows users to see at a glance what windows are open, as 
well as either Tile or Cascade all open windows. Finally, us- 
ing the mouse, users may automatically close, hide or open 
all Views. 


Debugging in Plan Works 

We present two small examples of how Plan Works can be 
used to find bugs in EUROPA 2 . 

Missing Model Rule 

Suppose that the rule governing rover movement was miss- 
ing a part: 


Rover : : Going { 

neq(to, from); // to != from 
meets (object .At aO); 
eq(a0.1, to); 
met-by missing 


} 

The resulting plan could then have two consecutive 
Rover: : Going tokens; this would appear in the Timeline View. 
From here, the user could proceed in several ways. One op- 
tion is to launch the Token Network View and see that only 
one Rover: : At results as a subgoal from Rover : :Going. Upon 
opening the Rule Instance View, the user would see the rule 
text and the context in which the rule was invoked, and be 
able to revise the rule. Alternatively, the user could launch 
the Navigator View' and discover the problem. 

The Wrong Constraint 

As another example, supposer that the user used the wrong 
constraint m a rule: 


Rover: :Going{ 

eq(to, from); // to = from? silly! 

... > 

In this case, the user might see an unexpectedly very' long 
plan, which would appear in the Timeline View. Again, there 
are several candidate debugging scenarios. One option is 
for the user to open the Navigator View, and observe that 
Rover: : Going begets Rover: :At ad-infinitum. Opening a Rule 
Instance View on the Rover: : Going, the user might notice the 
incorrect use of the eq constraint. Another possibility is that 
the user immediately suspects a problem with constraint rea- 
soning, and opens the Constraint Network View. After find- 
ing the key of a parameter of a Rover: : Going, the user then 
can check the transactions enforced on this variable using 
the Transaction View'. Upon realizing that no neq constraints 
are enforced, the user can then check the Rule Instance View, 
and realize that the wrong constraint was used in the rule. 
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Figure 3: Plan Works Constraint Network View and Trans- 
action View'. 


Conclusions and Future Work 

We have described PlanWorks, a system designed to de- 
bug planning domains and planners. While PlanWorks 
was designed to debug planners built on top of the 
EUROPA 2 system, it can be used by any planner that obeys 
a small number of rules about how' to log its inner workings. 
PlanWorks was built largely with COTS technology, and has 
been fielded on Mac OSX 10.2 and 10.3, Linux and Solaris. 

PlanWorks w'as originally conceived of as an Inte- 
grated Development Environment for building and manag- 
ing projects with EUROPA 2 . In the near future, PlanWorks 
w ill be extended to handle visual model building, visualizing 
plan execution and associated constraint reasoning. Further- 
more, EUROPA 2 is designed to support many different plan- 
ning algorithms. We will also extend PlanWorks to enable 
user customization to visualize different planner algorithms 
and heuristics. 
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